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(54) Syntax parser for a video decompression processor 



(57) A video syntax parser (40) is provided tor a 
video decompression processor (20). A compressed bit- 
stream (106) is examined until a start code (100) is 
located. The start code (1 00) is decoded to enable a par- 
ticular parser state correspond ng thereto to be initiated. 
The parser state is communicated to a plurality of sub- 
systems (36. 42. 44. 46. 48. 52. 54. 56) of the video 



decompression processor (20). Each subsystem moni- 
tors the parser state to determine which parsed data fol- 
lowing the start code, if any. is intended for that 
subsystem. The subsystem then retrieves the parsed 
data it requires via a data bus (58) which receives the 
parsed data from the parser (40). 
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Description 

BACKGROUND OF THE INVENTION 

The present invention relates to a video decompres- 
sion processor, and more particularly to a video syntax 
parser for parsing out the fields of interest from a com- 
pressed video brtstream to various subsystems of the 
decompression processor. 

Digital transmission of television signals can deliver 
video and audio services of much higher quality than 
analog techniques. Digital transmission schemes are 
particularly advantageous for signals that are broadcast 
via a cable television network or by satellite to cable tel- 
evision affiliates and/or directly to home satellite televi- 
sion receivers, ft is expected that digital television 
transmitter and receiver systems will replace existing 
analog systems just as digital compact discs have 
rep l aced analog phonograph records in the audio indus- 
try. 

A substantial amount of digital data must be trans- 
mitted in any digital television system. In a digital televi- 
sion system, a subscrfoer receives the digital data 
stream via a receiver AJescrambler that provides video, 
audio and data to the subscriber. In order to most effi- 
ciently use the available radio frequency spectrum, it is 
advantageous to compress the digital television signals 
to minimize the amount of data that must be transmitted. 

The video portion of a television signal comprises a 
sequence of video "frames" that together provide a mov- 
ing picture. In digital television systems, each line of a 
video frame is defined by a sequence of digital data bits 
referred to as "pixels." A large amount of data is required 
to define each video frame of a television signal. For 
example, 7.4 megabits of data is required to provide one 
video frame at NTSC (National Television System Com- 
mittee) resolution. This assumes a 640 pixel by 480 line 
display is used with eight bits of intensity value for each 
of the primary colors red, green and blue At PAL (phase 
alternating line) resolution, 9.7 megabits of data is 
required to provide one video frame. In this instance, a 
704 pixel by 576 fine display is used with eight bits of 
intensity value for each of the primary colors red, green 
and blua In order to manage this amount of information, 
the data must be compressed. 

Video compression techniques enable the efficient 
transmission of digital video signals over conventional 
communication channels. Such techniques use com- 
pression algorithms that take advantage of the correla- 
tion among adjacent pixels in order to derive a more 
efficient representation of the important information in a 
video signal. The most powerful compression systems 
not only take advantage of spatial correlation, but can 
also utilize similarities among adjacent frames to further 
compact the data. In such systems, differential encoding 
is usually used to transmit only the difference between 
an actual frame and a prediction of the actual frame. The 
prediction is based on information derived from a previ- 
ous frame of the same video sequence. 



Examples of video compression systems using 
motion compensation can be found in Krause. et al. U.S 
patents 5,057,916; 5,068,724; 5,091,782; 5,093,720; 
and 5,235,419. Generally, such motion compensation 

5 systems take advantage of a block-matching motion esti- 
mation algorithm. In this case, a motion vector is deter- 
mined for each block in a current frame of an image by 
identifying a block in a previous frame which most closely 
resembles the particular current block. The entire current 

io frame can then be reconstructed at a decoder by sending 
the difference between the correspond ng block pairs, 
together with the motion vectors that are required to iden- 
tify the corresponding pairs. Often, the amount of trans- 
mitted data is further reduced by compressing both the 

15 displaced block differences and the motion vector sig- 
nals. Block matching motion estimating algorithms are 
particularly effective when combined with block-based 
spatial compression techniques such as the discrete 
cosine transform (OCT). Additional compression can be 

20 achieved using variable length coding to provide shorter 
length "code words" to events that are more likely to 
occur and longer code words to less likely events. At the 
receiver, the variable length code words are decoded by, 
eg., a Huffman decoder. An example of a Huffman 

2s decoder implementation can be found, for example, in 
US. patent 5,233,348 to Pollmann, et al. and incorpo- 
rated herein by reference: 

Each of a succession of digital video frames that 
form a video program can be categorized as an intra 

30 frame (l-frame), predicted frame (P -frame), or bidirec- 
tional frame (B-frame). The prediction is based upon the 
temporal correlation between successive frames. Por- 
tions of frames do not differ from one another over short 
periods of time. The encoding and d ecoding methods drf- 

35 fer for each type of picture. The simplest methods are 
those used for l-frames, followed by those for P-frames 
and then B-frames. 

l-frames completely describe a single frame without 
reference to any other frame. For improved error con- 

40 cealment motion vectors can be included with an I- 
trame. An error in an l-frame has the potential for greater 
impact on the displayed video since both P -frames and 
B-frames are precficted from an l-frame 

P-frames are predicted based on previous I or P 

45 frames. The reference is from an earlier I or P frame to 
a future P-frame and is therefore called "forward preop- 
tion." B-frames are predicted from the closest earlier I or 
P frame and the closest later I or P frame. The reference 
to a future picture (i.e., one that has not yet been dis- 

50 played) is called "backward prediction." There are cases 
where backward prediction is very useful in increasing 
the compression rata For example, in a scene in which 
a door opens, the current picture may predict what is 
behind the door based upon a future picture in which the 

55 door is already open. 

B-frames yield the most compression but also incor- 
porate the most error. To eliminate error propagation, B- 
frames may never be predicted from other B-frames. P- 
frames yield less error and less compression, l-frames 
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yield the least compression, but are able to provide ran- 
dom access entry points into a video sequence. 

One standard that has been adopted for encoding 
digital video signals is the Motion Picture Experts Group 
(MPEG) standard, and more particularly the MPEG-2 
standard. This standard does not specify any particular 
distribution that l-frames, P -frames and B-frames must 
take within a sequence Instead, the standard allows dif- 
ferent distributions to provide different degrees of com- 
pression and random accessfoilrty. One common 
distribution is to have l-frames about every hatf second 
and two B-frames between successive I or P frames. To 
decode P frames, the previous l-frame must be availabla 
Simflarty, to decode B frames, the previous and future P 
or I frames must be availabla Consequently, the video 
frames are encoded in dependency order, such that all 
pictures used for prediction are coded before the pictures 
predicted therefrom. Further details of the MPEG-2 
standard (and the alternative DigiCipher®ll standard) 
and its implementation in a video decompression proc- 
essor can be found in document MC68VD P/D, a prelim- 
inary data sheet entitled "MPEG-2/DCII Video 
Decompr e ssion Processor," 9 Motorola Microprocessor 
and Memory Technologies Group, 1994, incorporated 
herein by reference 

In order to implement video compression in practical 
systems, a video decompression processor is required 
for each digital television receiver. The development of 
very large scale int egr ation (VLSI) integrated circuit 
chips is currently underway to implement such video 
decompression processors. In consumer products such 
as television sets, it is imperative that the cost of the sys- 
tem components be kept as low as possible. 

One important subsystem of a video decompression 
processor is known as the video syntax parser. This sub- 
system is responsible for parsing out the fields of interest 
from the compressed video brtstream, which may be, tor 
example, in the DigiCipher II or MPEG-2 syntax. Typi- 
cally, the parser will receive its data from an external ran- 
dom access memory. Different subsystems of the video 
decompression processor will require different fields of 
data from the incoming bftstream. For example, a motion 
vector decoder will require motion vectors carried in the 
bftstream. A variable length code word decoder such as 
a Huffman decoder within the decompression processor 
will require the code words for decoding into transform 
coefficients. Other subsystems of the video decompres- 
sion processor will also require various information car- 
ried in the brtstream. All of this information must be 
parsed from the brtstream and forwarded on to the appro- 
priate subsystem for further processing. The parser is a 
speed critical subsystem. It must obtain and parse the 
required data from the incoming bftstream on an efficient 
and orderly basis. Complexity of the parser must be 
reduced to the extent possible in order to keep its costs 
at a minimum. 

The present invention provides a video syntax 
parser that meets the aforementioned criteria. 



SUMMARY OF THE INVENTION 

In accordance with the present invention, a video 
syntax parser is provided for a video decompression 

5 processor. An input of the parser receives a compressed 
bftstream having data to be parsed. M eans are provided 
for parsing the data from the compressed bftstream. 
Means are also provided for decoding start codes con- 
tained in the data parsed from the compressed bit- 

w stream. Means responsive to a start code decoded by 
the decoding means initiate a particular parser state cor- 
responding to the start code. A parser state output com- 
municates the parser state to a plurality of subsystems 
of the video decompression processor. A data output is 

is provided for communicating parsed data from the pars- 
ing means to a data bus serving the plurality of subsys- 
tems. Each of the plurality of subsystems monitors the 
parser state to determine which, if any, parsed data on 
the data bus is intended for that subsystem. Each sub- 

20 system can then retrieve the parsed data intended for it 
In an illustrated errxxxfimerrt, the parsing means 
comprise shrft means coupled to recerveard temporarily 
store data from the compressed bftstream. The shift 
means are responsive to a shift length command for out- 

25 putting successive portions of the compressed brtstream 
to the decoding means. The shift means can comprise 
a barrel shifter. Data output from the barrel shifter is 
examined by the decoding means to locate start codes 
and to update the parser state during successive parser 

30 cycles between start codes. The output of the shift reg- 
ister abo provides the parsed data to the data output *x 
communication to the plurality of subsystems which 
selectively use the data. 

The barrel shifter can receive the compressed brt- 

35 stream from first and second registers. The first register 
is responsive to an enable signal for receiving the com- 
pressed brtstream data from a source, such as a video 
frame store. The second register is responsive to the 
enable signal for receiving successive portions of the 

40 compressed bftstream data from the first register. The 
enable signal is provided when the shift length command 
reaches or exceeds a predetermined value. 

The successive portions of compressed brtstream 
data provided to the decoding means will typically have 

45 a fixed length of N bits. The first and second registers 
are each N-bit registers and the barrel shifter shifts up to 
N bits at a time. 

The shift length command is a cumulative value 
which is incremented by a Held length" during succes- 

50 sive parsing cydes to control the number of bits by which 
the barrel shifter is shifted each cycle. The field length is 
dictated by the parser state during each cycla Means 
are provided for truncating the cumulative value to pro- 
vide a set of least significant bits for use as the shift 

55 length command and a more significant bit for providing 
the enable signal. In the illustrated embodiment, the five 
least significant bits of a six brt word are used as the shift 
length command and the most significant bit is used to 
provide the enable signal. 
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The compressed brtstream can include both fixed 
length words and variable length code words (VLC) to 
be parsed. In such an embodiment the parser further 
comprises a selector having a first input for receiving the 
field length and at least one second input for receiving a 
VLC length. Means responsive to the parser state actu- 
ate the selector to output the field length for incrementing 
the cumulative value during cycles when fixed length 
words are to be parsed from the brtstream and for actu- 
ating the selector to output a VLC length for incrementing 
the cumulative value during cycles when variable length 
code words are to be parsed from the brtstream. Means 
are provided for concurrently incrementing the cumula- 
tive value by a VLC length and an end of block (EOB) 
length at the end of a block of variable length data being 
parsed from the compressed brtstream. Such structure 
avoids the need to use a separate parser cycle just for 
an end of block message 

A rate flow buffer can be coupled between the 
source of the compressed brtstream (e.g., the external 
DRAM) and the register means that are used to load the 
brtstream data into the shift means. The rate flow buffer 
is responsive to the enable signal for buffering succes- 
sive portions of the compressed brtstream data from the 
source. In an illustrated embodiment, the rate flow buffer 
comprises a first-in first-out (FIFO) register coupled to 
receive data from a video frame store via a memory man- 
ager. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram of a video decompres- 
sion processor that incorporates a video syntax 
parser in accordance with the present invention; 
Figure 2 is a detailed block rJagram of the video syn- 
tax parser shown in Figure 1; 
Figure 3 is a diagrammatic illustration of a com- 
pressed brtstream including start codes and data to 
be parsed; 

Figure 4 is a timing diagram for the video syntax 
parser illustrated in Figure 2; and 
Figures 5a and 5b provide a flow chart Blustrating 
the operation of the video syntax parser of Figure 2. 

DETAILED DESCRIPTION QF THE INVENTION 

Figure 1 is a block diagram of a video decompres- 
sion processor incorporating a memory manager 30 that 
addresses external DRAM 22 to obtain data to be parsed 
in accordance with the present invention. The processor, 
generally designated 20, is a pipelined processor 
designed to decode both the transport layer (i.e. control 
and other non-video information) and the video layer of 
the compressed brtstream input via terminal 10, some- 
times referred to as the "transport packet interface" of 
the video processor. 

A user processor interface is provided at terminal 14 
tor control of the video data processor via an M-bus con- 
troller 50 that configures various registers in processor 



20. The M-bus is a two-wire, bidirectional serial bus 
which provides a simple and efficient means of data 
exchange between devices, and is fully compatible with 
the PC bus standard. 

5 An interface to the DRAM 22 is provided via address 
lines 24 and data lines 26. In the specific embodiment 
illustrated in Figure 1, DRAM 22 has a nine bit address 
port and a thirty-two bit data port. 

A video output interface 38 is provided for the 

io decompressed, reconstructed video which may, for 
example, be output as a standard CCIR (International 
Radio Consuftive Committee) 656, eight bit twenty- 
seven MHz multiplexed luminance (Y) and chromi na nce 
(Cr. Cb) signal. 

is A test interface can be provided via terminal 62 to a 
conventional JTAG (Joint Test Action Group) controller 
60. JTAG is a standardized boundary scan methodoiogy 
used for board-level testing to detect faults in package 
and board connections, as well as interna) circuitry. 

20 The video decom pre ssion processor 20 receives a 
clock signal via terminal 12. The clock provides timing 
information for, e.g., enabling a transport syntax parser 
32 to recover timing information and video information 
from transport packets in the compressed bit stream 

25 input via terminal 10. An acquisition and error manage- 
ment circuit 34 utilizes a program clock reference (PCR) 
and decode time stamp (DTS) detected by a video syn- 
tax parser 40 to synchronize the start of picture decod- 
ing. This circuit sets vertical synchronization and 

30 provides global synchronization for all video decode and 
display functions. 

The video layer is buffered in an input buffer (FIFO) 
configured in the external DRAM 22 by memory manager 
30. The video syntax parser 40 receives the compressed 

36 video data output from the DRAM FIFO via memory 
manager 30, and separates the motion vector informa- 
tion from the coefficients describing the video informa- 
tion. The coefficients are processed by a Huffman 
decoder 52. inverse quantizer 54, and inverse discrete 

40 cosine transform (IDCT) processor 56. 

Motion vectors are recovered and used to address 
previously decoded video frames required for recon- 
structing a current video frame. In particular, a motion 
vector decoder 42 decodes the motion vectors received 

45 from video syntax parser 40 and passes them to a pre- 
diction address generator 44. The prediction address 
generator provides address information necessary to 
retrieve, via memory manager 30, the necessary anchor 
frame data (i.e., I and P frame data) to enable prediction 

so calculator 46 to provide the prediction data necessary to 
reconstruct a current frame block Differential decoder 
48 combines the prediction data with the decoded coef- 
ficient data to provide decompressed video data. The 
decompressed data is stored in appropriate buffers of 

55 DRAM 22 via memory manager 30. 

It should be appreciated that the video decompres- 
sion process carried out by motion vector decoder 42, 
prediction address generator 44, prediction calculator 
46, differential decoder 48, Huffman decoder 52, inverse 
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quantizer 54 and IDCT 56 are conventional and well 
understood by those skilled in the art. 

Memory manager 30 schedules all activity on the 
external DRAM address and data buses 24, 26 and effi- 
ciently addresses DRAM 22 in accordance with the s 
present invention The memory manager insures that the 
data transfer requirements off the input FIFO portion of 
DRAM 22, the video syntax parser 40 and the video 
reconstruction circuit 36 (as well as prediction calculator 
46 and differential decoder 48) are all met. The video 10 
reconstruction circuit 36 calculates a current picture and 
inserts dosed caption, a vertical interval test signal 
(VTTS) and test pattern data for output on video output 
line 38. The output display is synchronized by comparing 
the PCR to a presentation time stamp (PTS). A deter mi- 75 
nation of when the decocfing and display of a video frame 
must commence is made by comparing a decode time 
stamp (DTS) to the PTS. 

The memory manager also provides a variable size 
for the FIFO portion of DRAM 22 depending on the 20 
decoding mode, which can be, for example, NTSC or PAL 
with or without bidirectional prediction frames (En- 
frames). The video buffer control ensures that the FIFO 
provided by DRAM 22 does not overflow or underflow. 
Buffer control is a function of system timing parameters 25 
including the PCR and DTS. 

DRAM 22 is illustrated as an external memory and 
may be provided by a plurality of DRAM chips, such as 
two, tour Mbit (megabit, i.a, 2 20 bits) DRAMs for an eight 
Mbit implementation or four, four Mbit DRAMs for a six- 30 
teen Mbit implementation, ft should be appreciated that 
in future implementations, and as memory technology 
advances, DRAM 22 may be provided as internal mem- 
ory within the video decompression processor. The 
DRAM is mapped to provide various decode and output 35 
video buffers as well as a circular FIFO tor the com- 
pressed input video bitstream. The DRAM may also be 
used to provide a test pattern buffer, a VTTS buffer and 
a closed captioning display reordering buffer as well as 
to store various picture structure data necessary to prop- 40 
erry display the decoded video frames. The DRAM can 
be reinitialized via memory manager 30 to provide differ- 
ent memory maps as required when variables are mod- 
ified such as the video frame vertical size, PAL or NTSC 
video, the presence of test patterns, eight or sixteen Mbit 45 
memory configuration, and whether B-frames are 
present 

The memory manager 30 schedules all of the activ- 
ity on the external DRAM buses including the data trans- 
fer requirements of the input FIFO, the video parser and so 
the video reconstruction circuit The memory manager 
also performs the required DRAM refresh in a conven- 
tional manner. For example, the same row in each of two 
or four external DRAMs can be refreshed simultane- 
ously. 55 

A small amount of FIFO can be provided as a rate 
flow buffer between the memory manager 30 and each 
of the components that accesses data from DRAM 22. 
For example, video syntax parser 40 contains a small 



rate flow buffer 72 (Figure 2) in the path which receives 
data from DRAM 22 via memory manager 30. The video 
syntax parser requires a new data word fairly infre- 
quently. However, when a new word is required the 
parser must have it immediately. Otherwise, downstream 
processes that require an output from the video syntax 
parser sit idle, reducing the efficiency of the video 
decompression processor. If video syntax parser 40 
were to make individual requests to the D RAM each time 
it needed a new data word, a slow random access would 
result and the parsing process would be delayed. The 
provision of the rate flow buffer overcomes this potential 
problem, ff, for example, the rate flow buffer can hold 
twenty words of DRAM data, the video syntax parser wiD 
be able to obtain a new data word that it requires imme- 
diately from the rate flow buffer. When th e rat e flow buffer 
reaches a certain preset level of emptiness, memory 
manager 30 is directed to read more data from the RAM. 
When the request for more D RAM data is serviced, the 
data is read in a sequential burst and stored to the rate 
flow buffer untfl it is full. 

The rate flow buffer helps DRAM I/O bandwidth and 
decoder speed because accesses are sequential and 
fast, usually within the same row of the DRAM, and the 
parser rarely runs out of data. More particularly, a 
request can be put in for new data before the rate flow 
buffer has emptied completely. 

As indicated in Figure 1, video syntax parser 40 
receives compressed bitstream information from DRAM 
22 via memory manager 30. The parser also receives 
various acquisition and error management information 
from circuit 34. Motion vector decoder 42 provides vari- 
ous handshaking information to the parser, including, for 
example, macrobtock data requests, identification of the 
picture coding type, macroblock type information which 
is decoded by the motion vector decoder after being 
parsed out from the video syntax parser, and the variable 
code length of macroblock data. The video syntax parser 
also receives certain handshaking information from the 
Huffman decoder 52. This information includes block 
data requests, macroblock end information, the length of 
variable length codes for data blocks, and an end of block 
length identifier. Other handshaking information, such as 
vertical blanking interval user data requests and a parser 
enabl e signal are received either directly or via the acqui- 
sition and error management circuit 34. 

The video syntax parser includes two output buses. 
Bus 57 provides the parser state to each of a plurality of 
subsystems (i.e., the motion vector decoder 42, predic- 
tion address generator 44, prediction calculator 46, dif- 
ferential decoder 48. Huffman decoder 52, inverse 
quantizer 54, IDCT 56 and video reconstruction circuit 
36) of video decompression processor 20. A data bus 58 
(X>mrnunicates parsed data from the video syntax parser 
to the various subsystems of the video decompression 
processor requiring such data. Each subsystem coupled 
to buses 57 and 58 will monitor the current parser state 
to determine if subsequent data in the parsed data 
stream is intended tor that subsystem. If the parser state 
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indicates that parsed data tor the subsystem follows, the 
subsystem will retrieve that data and process it accord- 
ingly. 

The video syntax parser is illustrated in greater detail 
in Figure 2. The compressed brtstream information to be 
parsed is received from DRAM 22 via memory manager 
30 at terminal 70. The data is buffered in FIFO 72 for 
subsequent transfer to a first register 74. In the particular 
implementation illustrated, register 74 is a 32 bit register, 
although those skilled in the art will appreciate that the 
data can be processed in different word lengths depend- 
ing upon particular system requirements. Initially, a first 
32 bits of information are loaded into register 74. During 
a subsequent dock cycle, the contents of register 74 are 
loaded into register 76 while register 74 receives another 
32 bits of info rmati on from FIFO 72. 

A barrel shifter (or equivalent shift means) 78 
receives the data from registers 74 and 76 for subse- 
quent output of appropriate portions thereof to decoder 
80 and to the parser data bus 58. 

One purpose of decoder 80 is to search for start 
codes in the data output from barrel shifter 78. Decoder 
80 can be implemented as a state machine. Once a start 
code is located and decoded, the current state of the 
state machine wiO determine the length of the next field 
in the video syntax. That length updates a shift length by 
which the barrel shifter shifts. A running total of the five 
least significant bits (LSB's) of the shift length is main- 
tained in a shift length accumulator 92 and is applied to 
the shift length input of the barrel shifter. The most sig- 
nificant bit (MSB) of the six bit shift length is used to actu- 
ate shifts of greater than 31 bits. Such shifts are provided 
by transferring the contents of f irst register 74 to second 
register 76. At the same time, first register 74 will receive 
new data from FIFO 72. During the next cycle, new data 
from FIFO 72 is presented to register 74 in response to 
a FIFO enable signal, which is the enable signal used to 
actuate registers 74 and 76 delayed by one clock cycle 
by DMypefBpflop94. 

Figure 3 illustrates, in diagrammatic form, a com- 
pressed brtstream to be parsed by the video syntax 
parser of Figure 2. The decoder 80 monitors successive 
32 bit words output from barrel shifter 78 to locate a start 
coda Since the brtstream is provided in a byte aligned 
manner, in searching for a start code the barrel shifter is 
successively shifted by one byte (8 bits) at a time until a 
24 bit start code sequence 102 is found in the 32 bit start 
code 100. For example, start code sequence 102 can 
comprise a series of 23 zeros followed by a binary "1". 
Upon recognition of this sequence, decoder 80 will 
decode the next byte, which comprises an 8-bit start 
code identification (ID) 104. The start code ID identifies 
the particular category of information following the start 
coda The following information is the actual data 106 to 
be parsed out to the different subsystems of decompres- 
sion processor 20. 

The various categories of data to be parsed are dic- 
tated by the MPEG-2 or Digi Cipher II standards. The 
MPEG-2 standard is descrfoed in detail in the Interna- 



tiona] Standards Organization publication no. ISO/IEC 
13818-2 entitled "Coding of Moving Pictures and Asso- 
ciated Audio," incorporated herein by reference. The cat- 
egories of information that can be identified by the start 

5 code identifier 104 in an MPEG-2 or DCII embodiment 
can include, for example, a sequence header, sequence 
extension, extension and user data, user data, sequence 
display extension, group of pictures header, picture 
header, picture extension, picture data, slice layer, mac- 
ro robtock layer, and block layer. 

various different information is included within each 
of the categories. For example, a start code identifying 
a sequence header means that the subsequent data to 
be parsed includes a sequence header coda horizontal 

is size value, vertical size, sample aspect ratio, frame rate, 
bit rate, buffer size information, and may also include an 
intra quantizer matrix and/or a noointra quantizer matrix. 
In addition, sequence header information can comprise 
various marker bits and flags necessary to property 

20 parse and decode the data. Each of the other categories 
referred to above will comprise their own layers of infor- 
mation to be used by different subsystems within the 
video decompression processor. Since the location of 
each of the various information types contained in the 

25 compressed brtstream is dictated by the MPEG and 
DigiCipher standards, once the start code is located the 
identity and location of all following information until the 
next start code is easily identifiable, e g., by the use of 
look up tables which can be provided in synthesized read 

30 only memories. The video syntax parser 40 will contain 
a look up table tor the length of each subsequent field in 
the data to be parsed following a start code. Look up 
tables for decoding the data itself are provided in the var- 
ious subsystems of the video decompression processor 

35 that communicate with the video syntax parser. For 
example, motion vector decoder 42 and Huffman 
decoder 52 decode and feed back various handshaking 
information to the video syntax parser as described 
above. 

40 While searching for a start code, decoder 80 will out- 
put a "field length" signal to cause barrel shifter 78 to be 
shifted by one byte (8 bits) during each successive 
parser cycle. The field length output from decoder 80 is 
coupled to an adder 88 via selector 84. The selector 84 

45 can output any one of three signals input thereto, in 
response to the current parser state input via terminal 
98. When the parser is initially attempting to locate a first 
start code, the parser state will be in a signal acquisition 
mode that will cause selector 84 to output the 8-bft field 

so length for summation with the previous shift length output 
from shift length accumulator 92. The previous shift 
length is input to adder 88 via an adder 86. The purpose 
of adder 86 is to increase the shift by an end of block 
(EOB) length at the end of every block of DCT coeffi- 

55 dents processed by the Huffman decoder. The EOB 
length is output from the Huffman decoder 52 and is 
summed with the last variable length coded coefficient 
in each block to avoid the need to waste a separate clock 
cycle just for the EOB length. 
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After the field length is added to the prior shift length 
in adder 88. the result is truncated in circuit 90 to provide 
the five least significant bits of the sum to shift length 
accumulator 92 and the most significant sixth bit to tip 
f top 94. This sixth bit provides the enable signal for reg- 
isters 74 and 76. which load new data each time the state 
of the bit changes. The bit is aJso delayed by the flip flop 
94 and used to enable the FIFO 72 to present data for 
loading into register 74 during the next enable cycle. 

Upon locating a start code and decoding the start 
code identifier, a new parser state wfll be output from 
decoder 80 and stored in parser state register 82. The 
parser state is also communicated to each of the decom- 
pression processor subsystems coupled to parser state 
bus 57. As subsequent data is decoded, the parser state 
wiB change and wfll indicate to each subsystem which 
data is present so that the subsystems can retrieve 
appropriate data for further processing. 

The various handshaking information referred to 
above is input to decoder 80 via terminal 96. This infor- 
mation can include a macrobfock data request block 
data request, macrobfock type, picture coding type, mac- 
robfock end. VBI user data request and/or a parser ena- 
ble signal. When variable length code words are being 
decoded instead of fixed length words, the length of each 
code word is input to selector 84 from motion vector 
decoder 42 in the case of a macrobfock (MB VLC length) 
or from Huffman decoder 52 in the case where the code 
word is representative of data from an individual block 
(BLOCK VLC length). The parser state input at terminal 
98 win actuate selector 84 to output the BLOCK VLC or 
MB VLC length as appropriate. 

Figure 4 is a timing diagram for various signals within 
me video syntax parser. Signals 1 1 0 and 1 1 2 are 54 MHz 
and 27 MHz clocks, respectively. Signal 114 represents 
the output from barrel shifter 78. As indicated, various 
delays inherent in the parser provide very tight timing 
during which limited opportunities are available for per- 
forming parser operations. Signal 116 represents the 
output from the lookup table that provides the length of 
each variable length code word. The output from the shift 
length adder 88 and the timing of the shift length bits 
input to accumulator 92 is represented by timing line 1 1 8. 
The shift length residual is indicated by tinting line 120. 
The loading of the first and second registers 74. 76 is 
indicated by signals 122. 124 which are responsive to 
the enable signal 1 26. As can be seen, the FIFO enable 
signal 128 is delayed by one dock cycia The output of 
FIFO 72 is indicated by timing line 130. An example of 
different parser states, including times where fixed length 
(FLC) and variable length (VLC) codes are being proc- 
essed is indicated at 1 32. The length of fixed length code 
words (my-length) output from the decoder 80 is indi- 
cated at 134. A macrobfock data request signal from 
motion vector decoder 42 is indicated at 136. 

Figures 5a and 5b comprise a flowchart illustrating 
the operation of the parser. The flowchart begins at 1 50. 
and at box 152 the barrel shifter output is examined by 
decoder 80 (Figure 2) in search of an initial start code. If 



the first 32 bits presented to the decoder do not represent 
a start code, as determined at box 154. the shift length 
(which starts out at zero) is incremented by the field 
length, which is set to eight bits when the decoder is 

5 searching for a start coda The incrementing of the shift 
length is indicated at box 156. At box 158. a determina- 
tion is made as to whether the shift length exceeds a 
value of 32. H it does, the state of the most significant bit 
of the six bit sum from adder 88 will change, generating 

10 an enable signal to shift new data from the FIFO 72 to 
register 74 as indicated at box 160. At the same time, 
the old data from register 74 wiO be loaded into register 
76. After the data has been shifted, or in the event that 
the shift length cfid not exceed a value of 32. the data in 

is the barrel shifter wfll be shifted by the shift length as indi- 
cated at box 162. 

The routine then continues with the decoder 80 
searching successive 32 bit words (each shifted eight 
bits with respect to the previous word) until the first start 

20 code is located A! this point, the routine wfll pass from 
box 1 54 to box 1 64 where the start code ID is decoded. 
This wffi identity the category of information following the 
start code, and the parser state wiD then be set accord- 
ingly at box 1 66. At box 1 68, a determination is made as 

25 to whether the next field of data is fixed length data. If so, 
the field length is set at box 170 so that the next shift 
length can be computed as indicated at box 1 72. 

At box 174 (Figure 5b) a determination is made as 
to whether the new shift length exceeds a value of 32. If 

30 so, registers 74 and 76 will be enabled to receive new 
data. FIFO 72 will also be enabled during the subsequent 
parser cycle to present new data at the input of register 
74. 

At box 178, the barrel shifter is shifted by the new 

35 shift length and the barrel shifter output is then decoded 
as indicated at box 180. At box 182, a determination is 
made as to whether any of the subsystems receiving 
data from the parser have requested the parser opera- 
tion to be temporarily put on hold. For example, Huffman 

40 decoder 52 may temporarily need to stop the parser to 
allow a code word to be decoded into more than one 
coefficient To do this, a block data request signal will be 
communicated from the Huffman decoder to the decoder 
80 of the video syntax parser via handshake input 96. 

45 When a hold is requested, box 1 84 monitors the situation 
to determine when a resume command (or release of the 
hold command) is received. When this happens, the rou- 
tine proceeds back to box 182 and when no further holds 
are present a determination is made at box 186 as to 

so whether any errors have occurred that would require 
reacquisrtion of the brtstream. For example, if the 
sequence of data has been lost such that a next start 
code can not be located, it will be necessary to return 
back to box 152 to acquire an initial start code so that 

55 parsing of the brtstream can recommence. Thus, box 186 
provides an escape path in the event that subsequent 
start codes in the compressed brtstream are not located 
when expected. At box 1 88, a determination is made as 
to whether a new start code has been received when 
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expected during normal processing of the brtstream. If 
so, the start code identification is decoded as indicated 
at box 1 90, and the routine returns back to box 1 66 (Fig- 
ure 5a) where the new parser state dictated by the 
decoded start code ID is set. 5 

In the event that variable length data is encountered 
in the brtstream, the routine will flow from box 168 to box 
192 (Figure 5b) where a determination is made as to 
whether a block variable length code word is present. If 
so, the shift length will be incremented by the block VLC w 
length input to selector 84 from Huffman decoder 52. 
Otherwise, macrobtock variable length data wiD be 
present and the shift length will be incremented by the 
MB VLC length as indicated at box 194. At the end of 
each block, Huffman decoder 52 will provide an EOB is 
length to adder 86 as indicated at box 198, so that the 
shift length can be additionally incremented by the end 
of block length, as shown at box 200. The process con- 
tinues to box 174 to enable each subsequent portion of 
data between start codes to be property parsed and 20 
passed on to the appropriate subsystem. 

It should now be appreciated that the present inven- 
tion provides a syntax parser for parsing out the fields of 
interest from, e.g., the MPEG-2 or DigiCipher II syntax. 
Variable length code fields are parsed with feedback 2s 
from the VLC decoder to determine the end of the VLC 
field. The parser has a parser state bus and a data output 
bus. AH relevant areas of the syntax are uniquely defined 
by the current parser state, making it easy for each sub- 
system receiving data from the parser to determine when 30 
a field of interest to it is present Each subsystem 
decodes the current parser state and updates its regis- 
ters accordingly. 

Although the invention has been descrbed in con- 
nection with a specific embodiment thereof, those skilled 35 
in the art will appreciate that numerous adaptations and 
modifications may be made thereto without departing 
from the spirit and scope of the invention as set forth in 
the claims. 

40 

Claims 

1. In a video decompression processor, a video syntax 
parser comprising: 

an input for receiving a compressed bit- 45 
stream having data to be parsed; 

means for parsing said data from said com- 
pressed bitstream; 

means for decoding start codes contained in 
the data parsed from said compressed brtstream; so 

means responsive to a start code decoded by 
said decoding means for initiating a particular parser 
state corresponding to said start code; 

a parser state output for communicating said 
parser state to a plurality of subsystems of said video ss 
decompression processor; and 

a data output for communicating parsed data 
from said parsing means to a data bus serving said 
plurality of subsystems; 



each of said plurality of subsystems monitor- 
ing said parser state to determine which parsed data 
on said data bus, if any, is intended for that subsys- 
tem so that the subsystem can retrieve the parsed 
data intended therefor. 

2. A video syntax parser in accordance with claim 1 
wherein said parsing means comprise: 

shift means coupled to receive and shift data 
from said compressed brtstream, said shift means 
being responsive to a shift length command for out- 
putting successive portions of said compressed bit- 
stream to said decoding means. 

3. A video syntax parser in accordance with claim 2 
wherein said shift means comprise a barrel shifter. 

4. A video syntax parser in accordance with claim 2 or 
3 wherein said successive portions of said com- 
pressed bitstream are also output from said data 
output. 

& A video syntax parser in accordance with claim 3 
wherein said barrel shifter receives said com- 
pressed bitstream data from first and second regis- 
ters coupled to inputs of said barrel shifter, said first 
register being responsive to an enable signal for 
receiving said compressed bitstream data from a 
source and said second register being responsive 
to said enable signal for receiving successive por- 
tions of said compressed bitstream data from said 
fast register, said enable signal being provided when 
said shift length command reaches a predetermined 
value. 

6. A video syntax parser in accordance with claim 5 
wherein: 

said successive portions of compressed bit- 
stream data provided to said decoding means are 
each N bits in length; 

said first and second registers are each N-ort 
registers; and 

said barrel shifter shifts up to N bits at a time. 

7. A video syntax parser in accordance with one of 
claims 2 to 6 wherein: 

said shift length command is a cumulative 
value which is incremented by a field length during 
successive parsing cycles to control the number of 
bits by which said barrel shifter is shifted each cycle; 

said field length is dictated by said parser 
state during each cycle; and 

means are provided tor truncating said cumu- 
lative value to provide a set of least significant bits 
for use as said shift length command and a more 
significant bit for providing said enable signal. 

8. A video syntax parser in accordance with claim 7 
wherein said compressed bitstream includes both 
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fixed length words and variable length code words 
(VLC) to be parsed, said parser further corrxxising: 

a selector having a first input for receiving 
said field length and at least one second input for 
receiving a VLC length; and 5 

means responsive to said parser state for 
actuating said selector to output said field length for 
incrementing said cumulative value during cycles 
when fixed length words are to be parsed from said 
bitstream and for actuating said selector to output a 10 
VLC length for incrementing said cumulative value 
during cycles when variable length code words are 
to be parsed from said bitstream. 

9. A video syntax parser in accordance with claim 8fur- 75 
ther co m pris in g means for concurrently increment- 
ing said cumulative value by a VLC length and an 
end of block length at the end of a block of variable 
length data being parsed from said compressed bit- 
stream. 20 

10. A video syntax parser in accordance with one of 
claims 2 to 9 wherein said successive portions of 
sakJconrixessedbftstrearri are also output from said 
data output. 25 

11. A video syntax parser in accordance with one of 
claims 2 to 10 further comprising: 

register means responsive to an enable sig- 
nal for receiving said compressed bitstream data 30 
from a source and passing it to said shift means, said 
enable signal being provided when said shift length 
command reaches a predetermined value. 

12. A video syntax parser in accordance with claim 1 1 35 
further comprising a rate flow buffer coupled 
between said source and said register means, said 
rate flow buffer being responsive to said enable sig- 
nal for buffering successive portions of said com- 
pressed bitstream data from said source. 40 

13. A video syntax parser in accordance with any of the 
preceding claims wherein said decoding means 
continue to decode the data parsed from said data 
stream after said start code has been decoded to 45 
update said parser state during successive parser 
cycles unta a new start code occurs. 
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